Hm. My first thought is that the readme needs some pithy examples.

Other than that ✔️.

I love this! A note: you use 🚀 both as "multibase prefix" and as "digit 0", perhaps disambiguating the two is worthwhile 🤷

@ribasushi

you use rocket both as "multibase prefix" and as "digit 0", perhaps disambiguating the two is worthwhile

I don't really get why that an issue, whats the rational behind this ?
I believe the only thing we was trying to do is:

• we should attempt to use prefixes that doesn't encode in smaller / alternative bases (which I'm certain to have covered)
• the prefix should be in the alphabet (which is)

Would swapping 🚀 (0) and 🪐 (5) in the table by enough of a fix ?

No, I meant have 🚀 mean exclusively "this string is a mojibase encoding" and use 256 other distinct emojis used for the encoding. So all in all you will have 257 defined "atoms". I do not have a solid rationale for this, just feels "cleaner", given you character set is virtually unconstrained.

I have two counter arguments :

• I like rockets, the more rockets there is the happier I am. (It's not like it's taking the place of an other valuable emoji that could be represented, see the go impl code comments for emoji rational (btw if anyone has ideas for important emojies to include send it pls))
• Other bases don't do that, most of them use their biggest glyph as prefix. (Here I'm doing the reverse so inlined blocks have at least two rockets (key + identity multihash) because cid inlining is very cool and because all of the collision with smaller base thing is not an issue this time).

(I mean, if we're going to paint the bikeshed, we might as well paint it well)

The only real usecase I see is NFT artists bruteforcing cool emoji patern for their collection.

So I belive we need rockets and moons.
Then for the rest I've figurated that nft artists likely like the same emojies as the average peoples so I took a top list from unicode's popularity count.

But if anyone has thought thru propositions I'm for it.

I'm also in favour of using an emoji as prefix which is in the set of the 256 emojis

because cid inlining is very cool

It is not and I hope it's used less and less. It causes more trouble then good. The only use case I see is for data where the hash is bigger than the actual data. Though even then you're probably better off with other solutions, e.g. combining some of your data into bigger chunks.

@Jorropo : are you able to incorporate the input here, particularly around not supported emojis?

@BigLep

are you able to incorporate the input here, particularly around not supported emojis?

Yes, at first I didn't really wanted to, but since it seems that everyone think emojies that work is an important thing yes.
It's just really unimportant and havn't attempted to give me time to work on this yet.

New fixed version pushed.

Pls could you merge with git merge (not rebase) so the commit hash wont change and go-multibase's submodule wont need yet an other push.

yes multiformats/go-multibase#46
I'm just cleaning it up and also applying the requested changes, I'll push there soon

multiformats/go-multibase#46 is now ready for review too.

On my side it's RFM

Merge commits really grind my gears .. but since you insist and there's recent precedent in this repo I'll hold my nose

multiformats/js-multiformats#187 for JS impl